1. Field of the Invention
The present invention is directed in general to the field of data processing systems. In one aspect, the present invention relates to system clock management within data processing systems.
2. Description of the Related Art
Data processing systems and the applications that run on them rely on timing devices, such as clocks, to operate. For example, a conventional processor contains a system clock that uses a quartz crystal to generate a constant flow of pulses to allow the processor to operate and that also provides a timing reference to all of the other hardware logic in a data processing system. A number of userspace libraries and/or applications use the system clock to generate timestamps that are used for synchronization, for calculating dependencies (such as make), for controlling system hardware (such as determining when a cache memory should be refreshed) or for generating unique and/or random identification values, such as Universally Unique Identifiers (UUIDs). However, there can be timestamp collisions in such applications if the system clock has been reset backwards, or if there is an indication that the timestamp may have be set backward (such as during reboot). An example of such a timestamp-based application is a type 1 UUID library application that generates a time-based universally unique identifier (UUID) using the MAC network address of the host, a timestamp, and a clock sequence counter. If the clock on the host is reset backwards in time, the UUID specification states that the clock sequence counter must be incremented to avoid generating previously-generated UUIDs. See, IETF Proposed Standard RFC 4122, entitled “A Universally Unique IDentifier (UUID) URN Namespace.”
A variety of solutions have been proposed for dealing with a system clock setback event, but these solutions suffer from a number of drawbacks. For example, a sampling program can be run to monitor the system clock and detect any clock setback event, but because such sampling programs only work when they are active, they can not detect a clock setback event across system (re)boot events. Other systems (such as described in RFC 4122) propose to deal with clock setback events by including a clock sequence ID value in the timestamp that is incremented whenever the system clock is set backwards in time, but these systems do not provide a detection mechanism for determining if the system clock has been tampered with or set back in the first place. Other systems deal with the system clock setback problem by preventing a system clock setback from occurring at all. For example, the Multics (Multiplexed Information and Computing Service) operating system (OS) used the system clock to create unique IDs, but was configured to prevent the system clock from being reset backwards in time if the time was erroneously set into the far future and the system was booted. In other words, if the system clock was reset while the OS is not running, Multics refused to boot because of the possibility that the system might create a non-unique ID. To fix this situation, the entire Multics filesystem would have to be manually reviewed to find unique IDs that are in the future, and then these IDs would have to be reset to a safe value before manually resetting the system's concept of when the last time it was running, an unduly complex and time-consuming solution.
Accordingly, there is a need for a system and method of determining if the system clock has been set back in time. In addition, there is a need for an improved method, apparatus, and computer instructions for detecting system clock setback events across system boot events. There is also a need for a detection mechanism for determining if the system clock has been tampered with or set back. Further limitations and disadvantages of conventional clock management solutions will become apparent to one of skill in the art after reviewing the remainder of the present application with reference to the drawings and detailed description which follow.